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(57) Abstract 

An on-line incentive system provides a means for a consumer to enter an earning activity to earn value from the merchant. If the 
consumer qualifies, value, in the form of private label currency, is transferred from the merchant to the consumer without re-directing 
the consumer away from the merchant's web site. The merchant requests authorization to a clearinghouse site to transfer value from 
the merchant to the consumer via a value transfer network. The request is dispatched, via the Internet, from the merchant site to the 
clearinghouse site. If the value transfer is unsuccessful, then the incentive management system enters asynchronous retransmission mode, 
wherein the value transfer is periodically initiated from the merchant location to the clearinghouse location. At the clearinghouse site, 
authorization for the value transfer is determined, and a response message that indicates a status for the authorization is dispatched to the 
merchant. Thereafter, a response is sent to the consumer that indicates the status of the authorization request. 
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AN ON-LINE INCENTIVE SYSTEM 
BACKGROUND OF TH E I NVE N TION 

5 Field of the Invention: 

The present invention is directed toward the field of on-line incentive 
programs, and more particularly to a remote incentive management system that 
utilizes private label currency. 

10 Art Background; 

In general, merchants (e.g., proprietors of goods and services) 
participate in incentive programs to entice customers or consumers to purchase 
products or services. Typically, merchants participate in incentive programs to 
reward customers for purchasing merchandise. The merchant's general goal is 

15 to confer the maximum benefit on the customer while minimizing the merchant 1 s 
overhead and cost. 

One type of incentive program confers a single product or service 
to the customer as an award. The frequent flyer mile program is an example 
incentive program that confers a single predefined benefit to the customer. In a 

20 frequent flyer mile program, credit cards, associated with airlines, permit 
customers to receive frequent flyer miles in exchange for the customer's use of 
the credit card. The frequent flyer mile incentive programs typically award the 
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customer one frequent flyer mile for each dollar spent using the credit card. The 
customer subsequently redeems the frequent flyer miles earned for airline tickets 
or upgrades in accordance with the rules of the frequent flyer mile program. 

In a second type of incentive program, the customer may receive 
incentive "points" or stamps for a purchase based on the value of the purchase. 
For example, if a customer purchases a $1,000 item, then the customer may 
receive 1,000 points. For this type of incentive program, the customer is 
provided with a means for redeeming the points. Typically, the customer may 
select items from a catalog to redeem the points for merchandise or services. 
Although the catalog provides the customer with a greater selection than the 
predetermined benefit program, the customers benefit is constrained to items in 
the catalog. 

A merchant, when setting up the incentive program, must select how 
the customer will receive benefit from participation in the incentive program. 
For example, the merchant may set up the incentive program with a vendor or 
supplier of the value, such as a frequent flyer mile program, so that the customer 
receives a pie-determined benefit (e.g. , frequent flyer miles) after the customer 
purchases the merchant's product. Alternatively, the merchant may develop a 
catalog of merchandise for which the customer may redeem items based on the 
amount awarded. Accordingly, because the merchant desires to confer the 
maximum benefit on the customer, it is desirable, when implementing an 
incentive program, to provide the customer with a wide array of choices while 
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minimizing the overhead required by the merchant to implement the incentive 
program. 

As outlined above, incentive programs are currently used for credit 
card transactions, as well as customer transactions performed at a merchant's 
store. However, the Internet provides numerous opportunities for conducting 
transactions, including electronic commerce. The potential for commerce over 
the Internet is great because a user, through use of a computer logged onto the 
Internet, may reach a huge number of merchants. Because incentive programs 
are an effective way of motivating customers to purchase goods or services, it is 
desirable to implement an incentive program for use with the Internet. 

One implementation of an on-line incentive program is to completely 
implement the incentive program on a clearinghouse web site, distinct from 
merchants' web sites. For this implementation, a user is directed from a 
merchant's web site to the clearinghouse web site to conduct the transactions 
required to confer benefit upon the customer. However, directing the customer 
away from the merchant's web site is undesirable. Furthermore, because the 
incentive program is implemented solely at the clearing house site, the merchant 
loses all control over the parameters of the incentive program. Therefore, it is 
desirable to provide a balance between allowing the merchant to control certain 
aspects of the incentive program, while maximizing the benefit the customer 
receives for participating in the incentive programs. 

Networks have been developed to transfer sensitive financial 
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information, such as credit information, from a customer to a clearinghouse. For 
example, credit cards and automatic teller machines (ATM) cards are used in a 
secure fashion to transfer financial information from a consumer to a merchant 
via the credit card or bank clearinghouse. Because the systems are vulnerable to 
attack, many safeguards have been implemented to ensure that such transactions 
are secure to prevent fraud and theft. However, these general safeguards are 
tailored to accommodate value transactions from a consumer to a merchant. As 
is described fully below, the present invention implements a value transfer 
network that implements safeguards and protections to optimize a system that 
transfers value from merchants to consumers (i.e., in the reverse direction of the 
typical purchase transaction). 

SUMMARY OF THE INVENTION 
An on-line incentive system provides a means for a consumer to 
enter an earning activity to earn value from the merchant. The value is initially 
conferred in the form of private label currency. If the consumer qualifies, value 
is transferred from the merchant to the consumer without re-directing the 
consumer away from the merchant's web site. In this way, the consumer's focus 
of activity remains at the merchant's web site. At the clearinghouse, the 
consumer is provided a means to redeem the private label currency value for 
goods and services. 

In one embodiment, software at the merchant's web site determines 
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whether the consumer qualifies to earn value by defining parameters that 
determine the earning activity, A request for authorization, originating at the 
merchant's location, is dispatched to a clearinghouse to transfer value from the 
merchant to the consumer. In one embodiment, the functionality that determines 
whether the consumer qualifies to earn value is performed on the merchant's web 
server, payment server or fulfillment server, and the functionality to request 
authorization to a clearinghouse resides on a separate remote incentive 
management server. 

In one embodiment, the incentive management system includes a 
value transfer network. The value transfer network provide a secure and reliable 
means to transfer value from a merchant to a consumer. Through use of the 
value transfer network, a request is generated, at the merchant's location, to 
authorize a value transfer from a merchant's account to a consumer's account. 
The request is dispatched, via the Internet or a private network, from the 
merchant site to the clearinghouse site. If the value transfer is unsuccessful, then 
the incentive management system enters an asynchronous retransmission mode, 
wherein the value transfer is periodically initiated from the merchant location to 
the clearinghouse location until a transaction confirmation is received at the 
clearinghouse site. Also, the value transfer, signed and encrypted, is logged in 
the form of human readable text. At the clearinghouse site, authorization for the 
value transfer is determined, and a response message that indicates a status for 
the authorization is dispatched to the merchant. Thereafter, a response is sent to 
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the consumer that indicates the status of the authorization request. The consumer 
may receive a response via e-maii. Thus, the consumer receives a real-time 
response regarding the result of the value transfer. 

. The earning activity may include any action or response the 
merchant seeks to elicit from the consumer. In one embodiment, the merchant 
seeks, in a "lend" earning activity, the lending of the consumer's attention in a 
manner pre-defined by the merchant. A "send" earning activity generally 
involves the merchant's desire for the consumer to send information requested 
by the merchant. In a "bend" earning activity, the merchant seeks to bend the 
behavior of the consumer in a manner pre-defined by the merchant. Also, a 
"spend" earning activity motivates the consumer to purchase merchandise or 
services offered by the merchant. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a diagram illustrating one embodiment for an on-line 
incentive system. 

Figures 2a - 2c illustrate an example of a consumer's host display 
during a real-time value transfer transaction in accordance with one embodiment 
of the present invention. 

Figure 3 illustrates one embodiment to deploy a remote incentive 
management system at the merchant's location. 

Figure 4 is a flow diagram illustrating one embodiment for remote 
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incentive management software operating at the merchant's location. 

Figure 5 is a fiow diagram illustrating one embodiment for 
processing a request for authorization message in the remote incentive 
management system. 

Figure 6 is a flow diagram illustrating one embodiment for 
processing request for point authorization (RFA) messages at the clearinghouse 
location. 

Figure 7 illustrates one embodiment of a remote incentive 
management system implemented at the merchant's location. 

Figure 8 is a flow diagram illustrating one embodiment for consumer 
private label currency redemption. 

Figure 9 illustrates a high level block diagram of a general purpose 
computer system in which the servers of the incentive system of the present 
invention may be implemented. 

DETAILED DESCRIPTION QF THE PREFERRED EMBODIMENTS 

Private Label Currency System : 

In a preferred embodiment, an incentive system involves interaction 
among a consumer, a merchant, and a clearinghouse. Figure 1 illustrates one 
embodiment for an on-line incentive system. In one embodiment, the incentive 
system is implemented as an Internet incentive system. In general, the incentive 
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system 100 involves three entities: a consumer 110, a merchant 120, and a 
clearinghouse 130. For purposes of simplicity, the consumer, merchant, and 
clearinghouse are referred to in the singular form; however, the incentive 
program typically supports many consumers and merchants, and may involve 
more than a single clearinghouse. For purposes of explanation, a consumer is 
any entity, whether an individual or business, for which a merchant desires to 
transfer or confer value. A merchant, as used herein, generally refers to any 
entity that desires to transfer value to a consumer in exchange for certain 
behavior or activity. A clearinghouse, as used herein, denotes an entity that 
redeems consumer value, conferred by the merchant, for services or goods of 
suppliers. 

In general, a consumer earns or receives value, or private label 
currency, from a merchant, and the consumer subsequently redeems the value for 
goods and services via the clearinghouse. In a preferred embodiment, the 
communications to support a value transfer from the merchant to the consumer, 
and the subsequent redemption by the consumer, occur over the open Internet. 
The "Z" shaped double headed arrows, shown on Figure 1, denote bi-directional 
communication via the Internet. Although the value transfer and value 
redemption of the present invention is described in conjunction with 
communication over the Internet, any form of communication, such as a direct 
telephone line connection, may be used without deviating from the spirit and 
scope of the invention. 
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In one embodiment, to receive value, the consumer 110 surfs up to 
a web site of merchant 120, and the consumer 110 enters an "earning activity", 
specified by the merchant 120. As described more fully below, the earning 
. activity may include any behavior or activity the merchant seeks to extract from 

5 the consumer 110. Once the consumer 110 has completed the earning activity 
to the satisfaction of the merchant 120, value for the earning activity is 
transferred from the merchant 120 to the clearinghouse 130. Thereafter, the 
consumer 110 may contact a web site, supported by the clearinghouse 130, to 
redeem value for goods and services. As described more fully below, the 

10 consumer 110 must perform a one time authorization to redeem the value at the 
clearinghouse 130. 

The incentive system consists of a plurality of merchants 120 who 
aie association with the clearinghouse 130. In general, the private label currency 
is not bound to a specific redemption item, such as frequent flyer miles, or bound 

IS to a specific catalog. With this system, the consumer 110 may earn value from 
different merchants, who participate in the incentive program, for deposit, and 
subsequent redemption, of the value at a single repository (e.g., the 
clearinghouse 130). In one embodiment, the value, or private label currency, is 
measured in points, and the consumer 110 redeems "X" points of the private label 

20 currency for "X" amount of services and/or products. 

The use of private label currency system of the present invention 
provides a vehicle for merchants to implement incentive programs while 
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protecting the pricing policies of the merchants. If an incentive program uses 
currency (e.g., cash or credit), then the consumer may readily ascertain, and 
consequently calculate, a monetary value for the value transferred from the 
merchant to the consumer For example, if a consumer receives, in an incentive 
program, one dollar of value for every one hundred dollars purchased, then the 
incentive discount is readily understood by the consumer. Thus, the use of 
public currency in an incentive program exposes the pricing policy (e.g., 
purchase price minus the amount of currency earned) directly to the consumer. 
However, with use of private label currency, which is later redeemed by the 
consumer for some other value, the monetary amount conferred by the merchant 
to the consumer is not readily evident, and thus the pricing policy of the 
merchant is preserved. 

In general, the clearinghouse 130 operates as a repository of value 
earned by the consumer at one or more merchants. As shown in Figure 1, the 
clearinghouse 130 is coupled to the suppliers 140, to indicate a relationship 
between the suppliers 140 and the clearinghouse 130. Specifically, the 
clearinghouse 130 transforms the private label currency for some form of value 
provided by the supplier 140. For example, the consumer 1 10 may redeem the 
private label currency for frequent flyer miles. In this example, the supplier 140 
represents an airline, or airline coalition, that awards frequent flyer miles to the 
consumer after the clearinghouse 130 transfers hard currency to the supplier 140 
(e.g. , airline provider). The consumer 110 may redeem the private label currency 
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for any type of value, such as cash, credit, tangible goods, services, etc. 

In one embodiment, the merchant 120 and clearinghouse 130 have 
a prearranged contractual relationship. Specifically, the merchant 120 purchases 
value or private label currency, and the clearinghouse 130 maintains a merchant 
account that reflects the amount of value held by that merchant. As described 
more fully below, as the consumer 110 earns value from a merchant, value is 
debited from the merchant account, and credited to the consumer account under 
predetermined rules (e.g., completion of all phases of the transaction). The 
clearinghouse 130 also maintains a consumer account from which the consumer, 
through a redemption process, transforms value into goods and/or services of 
suppliers 140. 

Figures 2a - 2c illustrate examples of consumer host displays during 
a real-time value transfer transaction in accordance with one embodiment of the 
present invention. The "Z shaped" line indicates communication over the Internet 
from the consumer's host to the merchant's web site. A consumer, utilizing a 
web browser, such as Netscape Navigator or Microsoft® Explorer, "surfs up" to 
a merchant's web site. In some way, the merchant's web site invites the 
consumer to enter an earning activity. Figure 2a illustrates an example display 
at the consumer's host that invites the consumer to commence an earning activity 
at the merchant's web site. As described more fully below, an earning activity 
may entice the consumer to: purchase products and/or services; lend time to a 
predefined activity on the merchant's web site; bend their behavior in some pre- 
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defined way; or send information about themselves to the merchant. 

In one embodiment, after the consumer enters the earning activity, 
the merchant notes that the consumer entered the earning activity, and verifies 
the operation of the remote incentive management system (Figure 3). If the 
incentive management system is not operable, then the merchant notifies the 
consumer host that value will not be earned at this time for the earning activity. 
If the incentive management system is operable, and the customer completes the 
earning activity, as defined by the merchant, then the merchant generates a 
request for authorization to the clearinghouse 130 (Figure 1). If the 
clearinghouse 130 authorizes the transaction in response to the request for 
authorization, then a response message is generated and sent to the merchant 120. 
Thereafter, the merchant 120 notifies the consumer 110 that value has been 
earned for the earning activity. 

Figure 2b illustrates an example display response to notify the 
consumer that the value has been earned (e.g. , congratulations you have earned 
value). If a failure occurs in the value transfer network (e.g., the network 
between the merchant 120 and the clearinghouse 130), then the consumer is 
notified that value will be earned pending verification that the earning activity 
and the consumer comply with predetermined rules or criteria as shown in the 
example display of Figure 2c. 

As illustrated by the above example, the incentive management 
system provides, with respect to the consumer, a "real-time" response to inform 



WO 00/21008 PCT/US99/23077 

13 

the consumer as to the status of the earning transaction. Accordingly, by 
providing a real-time response to the consumer regarding the consumer's value 
earned, the consumer receives a greater sense of satisfaction when participating 
in an incentive program, and is more likely to participate in additional incentive 

i 

programs. 

In one embodiment, the incentive management system of the present 
invention processes value or private label currency transactions as multiple phase 
transactions. The use of multiple phase transactions provides a rational model 
for debiting value from the merchant's account. In one embodiment, value 
transfer includes three phases: authorization, capture, and charge back. During 
the authorization phase, the clearinghouse determines whether the merchant has 
sufficient credit (e.g., value) to commit the transaction. During the second 
phase, capture, actual transfer of value occurs from the merchant's account into 
the consumer's account. The last phase, charge back, permits removing value 
from a consumer's account if, subsequent to the capture phase, circumstances 
arise that invalidate the transaction. In general, the clearinghouse implements the 
value transfer phases of authorization, capture, and charge back. Accordingly, 
although the clearinghouse conducts real-time authorization to deposit value into 
the consumers account, value is only ultimately conferred to the consumer 
pending the capture and charge back phases of the transaction. 

For the authorization phase, the incentive management system 
executes fnu/i control procedures to ensure that the consumer is valid (e.g., 
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consumer qualifies to receive the value), and it determines whether the merchant 
is capable of conferring the value. In one embodiment, to implement the capture 
phase, the incentive management system allows the merchant to view transactions 
to make a detennination as to whether the value, previously transferred from the 
merchant account to the consumer account, is valid. For example, if the earning 
activity is based on a consumer purchase, then the merchant capture and charge 
back phases may be consistent with the financial transactions associated with a 
purchase (e.g., a credit card transaction). For this example, if a dispute or 
charge back occurred with the credit card, then the merchant would not capture 
value for transfer to the consumer account. 

In one embodiment, to implement the capture phase, value is 
transferred to the consumer account after a predetermined amount of time unless 
the merchant explicitly voids the transaction. In a second embodiment to 
implement the capture phase, the merchant sends a confirmation to the incentive 
management system to commit the value transaction (e.g. , debit of the merchant 
account and credit of the consumer account). To implement a charge back in the 
incentive management system, the merchant executes an additional transaction 
to the clearinghouse to revoke value from the consumer (e.g., void the value 
transaction). 



Earning Activity! 

The "earning activity" for the incentive program may include any 
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activity or behavior that the merchant seeks to extract from the consumer. In one 
embodiment, earning activities include events that occur across the entire 
consumer relationship cycle, including the introduction of relations between a 
consumer and a merchant. A "lend" earning activity involves the consumer 
lending some time and attention to an activity sought by the merchant. The lend 
earning activity may include any activity that requires the consumer to lend 
attention to the merchant. For example, the merchant may want consumers to 
read an advertisement posted on a merchant's web page. 

A "send" earning activity involves the consumer sending information 
about themselves to the merchant. The merchant may desire to award value to 
consumers for a send earning activity in order to conduct market research. For 
example, the merchant may request, for a send earning activity, that the 
consumer complete a survey that includes preferences, tastes, demographic 
information, etc. 

A third earning activity, referred to as a "bend" earning activity, is 
used by the merchant to change the behavior of a consumer. For example, a 
bank may desire to award those customers who use an on-line banking service 
to conduct bank transactions. For this example, the merchant seeks to change the 
behavior of a consumer by enticing the consumer to use on-line banking services 
instead of using a live teller. By further way of example, in an attempt to reduce 
overhead, a delivery service may want its customers to place orders through an 
on-line delivery request form. 
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A fourth category of earning activity, referred to as a "spend" 
earning activity, involves a merchant that rewards consumers for purchasing 
products and/or services from the merchant. For example, a merchant may 
award value to a consumer based on the dollar amount of the consumer purchase. 

Remote Incentive Management Sy stem Dep loyment: 

Figure 3 illustrates one embodiment to deploy a remote incentive 
management system at the merchant's location. The remote incentive 
management server 315, and software operating thereon, is characterized as 
"remote" because the functionality is implemented at the merchant's location, and 
is thus remote from the clearinghouse location. For this implementation, the 
merchant 120 (Figure 1) includes a merchant web server 300, a remote incentive 
management server 315, a transaction log 320, and the merchant's firewall 325. 
In addition, software running on the merchant's web server 300 communicates 
with software running on the remote incentive management server 315 via a 
request for authorization-application program interface (RFA-API) 310. In one 
embodiment, the merchant's web server 300 and remote incentive management 
server 315 are coupled at the merchant's location via a local area network 
(LAN). 

An implementation for the clearinghouse is also shown in Figure 3. 
The clearinghouse is implemented through a consumer's account server/database 
335, clearinghouse incentive management server 340, merchant's account 
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database 350, and the clearinghouse firewall 355. The consumer, who interacts 
with both the merchant and clearinghouse, is represented by block J3U, denoted 
as the consumers Internet access. The "Z" shaped lines, terminated with arrows, 
connote an interface over the Internet. The consumers Internet access 330 
communicates, over the Internet, to the merchant's web server 300, as well as 
the consumers account server/database 335. As described fiiUy below, the value 
transfer network involves communication over the Internet between the remote 
incentive management server 315 and the clearinghouse incentive management 
server 340. 

As shown in Figure 3, for this embodiment, the functionality for the 
remote incentive management system is implemented on a server (315) distinct 
from the merchant's web server 300. In addition, a merchant may have several 
web servers at the merchant's location, and one or more web servers may 
communicate to the remote incentive management server 315. In one alternative 
embodiment, functionality for the incentive management system is implemented 
remote from the merchant's location. For example, the incentive management 
system may be implemented as part of the payment and fulfillment system. In 
another alternative embodiment, the merchant's web server may include the 
remote incentive management system software, and may directly communicate 
to the clearinghouse incentive management server 340. However, running the 
remote incentive management software on a separate server than the merchant's 
web server has several advantages when implementing a remote incentive 
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management system. 

To implement the functionality of the remote incentive management 
software, as described herein, on the merchant's web server 300, significant 
modifications of the merchant's web server software would be required. For 
example, transactional software, which implements complex transactions such as 
electronic commerce, often requires replacing the merchant's web server 
software with entirely new software. The partitioning of the merchant's web 
server 300 with the remote incentive management server 315 is a very different 
solution for implementing complex transaction functionality at the merchant's 
location. For the incentive management system shown in Figure 3, the 
merchant's web server 300 requires minimal software running on the merchant's 
web server 300. 

The remote incentive management server 315 implementation allows 
for a clear and clean partition between the merchant's web server and functions 
associated with the incentive system. In general, the merchant's web server is 
a very vulnerable part of the overall perimeter security of the merchant's 
computer system. For purposes of security, a firewall, designated in Figure 3 
as merchant's firewall 325, is implemented to monitor and limit entry onto to the 
merchant's web server 300. The server division between the merchant's web 
server and the remote incentive management server allows for a clean partition 
of liability between the merchant and the clearinghouse. For example, if a 
security break in occurs on the merchant's web server due to a security breach, 
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then liability will not fall on the incentive management system due to the simple 
interaction (e.g. , one API call) between the merchant's web server 300 and the 
remote incentive management server 315. Thus, the remote incentive 
management server 315 does not compromise the security of the merchant's web 
server. If such a security breach does occur, the point of entry or break in, as 
between the merchant's web server software and the remote incentive 
management software, is evident. If the incentive management software was 
fully implemented on the merchant's web server, and a security break in or 
security breach occurred on the merchant's web server, then the incentive 
management software may be a point of attack that results in breach of the 
merchant's perimeter security. Furthermore, the server division allows the 
merchant to protect cryptographic keys that reside in the remote incentive 
management server 315 because the server 315 is not part of the outer perimeter 
of security at the merchant's location. 

The separation of functionality between the merchant's web server 
300 and the remote incentive management server 315 further allows for the 
merchant to fully define the earning activity. In a preferred embodiment, the 
merchant fully implements the functionality to support the earning activity on the 
merchant's web server 300. In this way, the merchant solely determines the 
conditions for which a consumer earns value through the earning activity. By 
allowing the merchant to fully -control the earning activity, the incentive 
management system provides the greatest flexibility to the merchant. 
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In one embodiment, the merchant's web server software 
communicates with the remote incentive management server software via the 
RFA-API 310. In general, the RFA-API 310 is an application program 
interface, which runs on the merchant's web server, that the merchant's software 
calls to start a value transaction. The RFA-API call starts a "client/server" 
transaction between the merchant's web server 300 and the remote incentive 
management server 315. The RFA-API provides the link to separate the process 
between the merchant's web server 300 and the remote incentive management 
server 315 to commence a value transfer transaction. 

As discussed more fully below, a call to the RFA-API, by the 
merchant software, signifies: entry of a consumer into the merchant defined 
earning activity; and the commencement of a value transfer to deposit value in 
the consumer's account. Because the RFA-API is conducted over a local area 
network, a less secure transaction between the merchant's web server 300 and the 
remote incentive management server 315 is required than a transaction that 
pierces the merchant's perimeter security. The RFA-API is ported across a wide 
variety of platforms to provide maximum flexibility to interface the merchant's 
web server software to the remote incentive management system software. In 
one embodiment, the RFA-API calls support calls from any programming 
language, such as C, C+ + , Perl, Java, etc. 

In one embodiment, as an enhancement to the incentive system, the 
remote incentive management system executes rules that define certain 
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parameters for the earning activity (i.e., earning activity rules). In general, the 
earning activity rules, executed by the remote incentive management system, 
facilitate the merchant's implementation of functionality that defines the earning 
activity. For example, earning activity rules, when executed, may impose 
5 limitations and constraints on the consumer's qualification to earn value in a 
manner desirable for many types of incentive programs. In one embodiment, the 
merchant may select which rules to enforce, and thereby customized the use of 
the earning activity rules. 

In another implementation for a remote incentive management 

10 system, a "minting engine" is executed at the consumer. In general, the minting 
engine performs the functionality to effectuate a value transfer from a merchant 
to the consumer. In one embodiment, the minting engine is software running on 
the consumer's computer. In operation, the consumer enters an earning activity, 
at the merchant's web site, to earn value from the merchant as described above. 

15 If the consumer qualifies, the merchant enables the consumer's minting engine 
to begin the value transfer from the merchant's account to the consumer's 
account. Thereafter, the consumer initiates a value transfer request to a 
clearinghouse to effectuate the transfer of value from the merchant to the 
consumer. 

20 



Value Transfer Network: 

In one embodiment, the incentive management system implements 
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functionality for a value transfer network through software operating on the 
remote incentive management server 3 15. Figure 4 is a now diagram iiiustraiing 
one embodiment for incentive management software operating at the merchant's 
location. Prior to executing a value transfer transaction, the consumer enters an 
earning activity on the merchant's web server, as shown in block 400. As shown 
in blocks 410 and 420, if the remote incentive management system is operable, 
then it records the consumer's entry into the earning activity. As shown in 
blocks 410 and 430, if the incentive management system is not operable, then the 
consumer is notified that value will not be awarded at this time for the earning 
activity. In one embodiment, the merchant's software determines whether the 
incentive management system is operable through a call to the RFA-API. A non- 
operable incentive management system may be a result of the remote incentive 
management server 315 being down. This initial call to the remote incentive 
system provides feedback to the consumer, such that if the remote incentive 
management system is not working, the consumer learns that he or she will not 
earn value for completion of the earning activity. This initial call significantly 
reduces the probability of failure in the value transfer network by insuring that 
the remote incentive management server 315 is initially operable. If a consumer 
is allowed to complete the earning activity without warning that the consumer 
will not receive value for the earning activity, then the consumer will be 
dissatisfied with the incentive program. Thus, with regard to the consumer, the 
initial check to determine operability of the remote incentive management server 
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315 permits a graceful shutdown of the incentive program. 

As shown in hlnrlr AACi nf Tomitv* A — * 
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system waits until the consumer completes the earning activity. When the 
consumer completes the earning activity, the merchant verifies the completion of 
the earning activity as shown in block 450. For example, the merchant may 
impose several conditions or rules on the earning activity, and this step verifies 
that the consumer complied with these rules or conditions. After verification, the 
merchant executes a second call to the incentive management system via the 
RFA-API as shown in block 460. As shown in block 470, the incentive 
management system creates a secure request for point authorization (RFA) 
message. In one embodiment, the RFA message is processed for transmission 
over the open Internet. In addition to creating the secure RFA message, the 
incentive management systems logs the RFA message in the transaction log 320 
(Figure 3) as shown in block 480. As shown in block 490, the RFA message is 
dispatched over the Internet to the clearinghouse. 

Figure 5 is a flow diagram illustrating one embodiment for 
processing a request for authorization message in the remote incentive 
management system. As discussed above, the remote incentive management 
system, operating at the merchant's location, creates a secure RFA message 
(block 470, Figure 4). As shown in block 500, the remote incentive management 
system generates a clear text message requesting the value transfer. Table 1 lists 
several fields for RFA message. 
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Merchant ID 



Sequence # 



Date Stamp 



Promotion ID 



Amount Awarded 



Consumer's E-Mail Address 



Authentication Token 



The merchant identification (ID) field uniquely identifies the merchant. The 
sequence # field stores a number to order or sequence multiple RFA messages. 
For example, multiple RFA messages may be transferred for a value transfer. 
With the sequence #, the clearinghouse incentive management server 340 may 
determine the original sequence of the messages. The date stamp, resolved to the 
nearest second, reflects the time the message was created, and thus uniquely 
identifies the message. A promotional ID field identifies the particular 
promotion for which the value has been earned. This permits the clearinghouse 
to track and record information regarding various promotions that a merchant 
may run. The RFA message further includes an amount awarded to the 
consumer. For example, if the private label currency is measured in points, then 
the amount awarded is a specific amount of points. The consumers e-mail 
address is also included so that the clearinghouse, if necessary, may attempt to 
contact the consumer. The last field shown in Table 1, the authentication token 
field, provides some sort of authentication, originated by the consumer, to bind 



WO 00/21008 PCT/US99/23077 

25 

the network identity of the consumer to a social identity of the consumer. 

The incentive management system encrypts the clear text RFA 
message as shown in block 510. In one embodiment, the incentive management 
system implements private key cryptography to encrypt RFA messages. 
Although the incentive management system is described using private key 
cryptography, any algorithm that encodes or encrypts the RFA message may be 
used without deviating from the spirit or scope of the invention. In a preferred 
embodiment, an encryption technique is used that optimizes security and speed 
of the encryption (i.e. , the level of security is maximized while the overhead to 
encrypt the message is minimized). In general, with private key cryptography, 
a single secret key is used to both encrypt a message as well as decrypt the 
message. Typically, public key cryptography is used when there are a large 
number of users. For example, to encrypt a message between a consumer and 
a merchant, a public key cryptography system would require excessive key 
management due to the large number of potential consumers. The private key 
cryptography algorithms may be executed more quickly than public key 
cryptography algorithms. However, private key cryptography introduces key 
management problems that do not exist in public key cryptography. In an 
incentive management system, there are relatively few merchants in relationship 
to the number of consumers. Accordingly, the key management problem is 
reduced because the keys are securely maintained by only the merchants and 
clearinghouse. 
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In one embodiment, the keys, to encrypt the RFA message, are 
stored in the remote incentive management server 315 (Figure 3). The remote 
incentive management server, which is isolated from the perimeter security of the 
merchant's location, provides a secure location to maintain the secret keys. 

As shown in block 520 of Figure 5, the remote incentive 
management system signs the encrypted message using a signature key. A digital 
signature technique is a well known technique to authenticate a message. As is 
well known, a digital signature is derived from the specific message, as well as 
the merchant's secret key. Specifically, the use of a digital signature 
authenticates that the message originated from the merchant, and thus the digital 
signature detects any tampering of the message that may have occurred over the 
open Internet. 

As shown in block 530, the signed/encrypted RFA message is 
dispatched to the clearinghouse over the Internet. In one embodiment, two 
protocols are used to transfer the signed/encrypted RFA message over the 
Internet. Because the RFA messages are relatively small, a UDP protocol can 
be used to transfer the RFA message. The UDP protocol is a highly unreliable 
protocol for transmitting messages over the Internet. In a second embodiment, 
the http protocol is used to transmit the RFA message. The http protocol, 
although requires higher overhead, is generally more reliable than the UDP 
protocol. Some merchants may only support a single protocol to reduce the 
complexity in maintaining perimeter security. For these merchant locations, the 
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http protocol may be used. If several protocols and ports are supported at the 
merchant site, then maintaining a secure perimeter at the merchant site becomes 
more difficult. 

In one embodiment, if the remote incentive management system does 
not receive a reply after a predetermined amount of time, the remote incentive 
management system repeats the functions in blocks 520 and 530 (e.g. , re-signs 
the encrypted RFA message and dispatches the new message to the clearinghouse 
over the Internet). In another embodiment, as shown in Figure 5, the remote 
incentive management system only repeats the function in block 530 by 
dispatching the new message to the clearinghouse over the Internet. If the 
remote incentive management system does receive a reply from the 
clearinghouse, then it logs the transaction in the transaction log 320 (Figure 3) 
as shown in block 550. In one embodiment, the transaction log 320 records all 
significant transactions that occur in the incentive system. The transaction log 
320 is a human readable text log to allow an administrator to manually review 
incentive system transactions. The entries to the transaction log 320 are signed 
and encrypted so that there is no possibility that a log message will be resent, 
thereby executing two value transfers for the same earning activity. 

As shown in block 560 of Figure 5, the incentive management 
system responds to the merchant's web server software (e.g., CGI program), 
with a response to the RFA message. Figure 6 is a flow diagram illustrating one 
embodiment for processing RFA messages at the clearinghouse location. As 
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shown in block 600, the clearinghouse receives the RFA message via the 
Internet. For purposes of explanation, the clearinghouse processes are executed 
on the clearinghouse incentive management server 340 (Figure 3). As shown in 
block 610, the clearinghouse incentive system validates the merchant's digital 
signature on the RFA message. In general, this step includes executing an 
algorithm to ascertain whether the RFA message had been forged, altered in 
transit, or damaged in transit. The clearinghouse incentive system also verifies 
that the RFA message was not already received (e.g., the RFA message has 
already been processed). If the RFA message was previously processed, then the 
clearinghouse incentive system confirms that value transfer has occurred. 

As shown in block 620, fraud control procedures are executed. In 
one embodiment, there are two general classes of fraud control procedures: 1) 
procedures derived from contractual terms between the merchant and the 
clearinghouse; and 2) statistical procedures that detect abnormal transactions. 
The contractual terms class of fraud procedures, which are dictated by the 
merchant, detect violations of rules that govern the transfer of value to a 
consumer. For example, the merchant may: limit the amount of value conferred 
to a consumer; limit the amount of times value may be transferred to a 
consumer; and limit the total value that may be transferred to a consumer. 
These rules are mere examples, and the merchant may define any constraints for 
subsequent implementation as fraud control procedures. 

The statistical fraud control procedures detect abnormal transactions, 
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and they are not merchant specific. For example, this class of fraud control 
procedures may detect that a single consumer is earning a significant amount of 
value from different merchants within a small period of time. Statistically, such 
an activity may identify fraud or abuse to the overall incentive system. A further 
example of this class of fraud control procedures includes detecting value transfer 
from a single consumer from multiple merchants at substantially the same time. 

As demonstrated in Figures 2a - 2c, the incentive system provides 
a real-time response to the consumer. Therefore, one important aspect of 
implementing fraud control procedures is the consideration of the amount of 
processing time required to execute the fraud control procedures. In one 
embodiment, a balance is stricken between the amount of fraud . control 
procedures executed during the real-time processing, and the response time 
associated therewith. For example, the incentive management system may 
balance the results obtained from executing fraud control procedures against the 
amount of time taken to execute the procedure. 

If the fraud control procedures detect fraud (e.g., abnormal 
behavior), then the clearinghouse incentive system generates a digitally signed 
and encrypted response message that indicates detection of fraud as shown in 
blocks 630 and 650 of Figure 6. Alternatively, if fraud is not detected, then the 
clearinghouse incentive system executes a two phase transaction commitment to 
debit the merchant's account and credit the consumer's account the value 
specified in the RFA message, as shown in blocks 630 and 640. The 
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clearinghouse incentive system utilizes the merchant ID and the authentication 
token fields of the RFA message to debit the merchant account and credit the 
consumer account. As discussed above, although the authentication phase is 
executed at this time, post solution activity {e.g. , capture and charge back), may 
occur to reverse the transaction. 

As shown in block 650, the clearinghouse incentive system generates 
a response message. Table 2 lists a number of fields for a response message 
configured in accordance with one embodiment. 

Table 2 

Sequence # 

Merchant ID 

Time 

Status Code 

The clearinghouse incentive system, to generate the response message, calculates 
a sequence number for the sequence # field. The sequence number mimics the 
sequence number contained in the RFA message. The merchant ID, also 
contained in the RFA message, uniquely identifies the corresponding merchant. 
The time field inserts a date stamp, resolved to the nearest second, for the 
response message. The status code field, listed in Table 2, indicates a status for 
the corresponding RFA message. In one embodiment, the clearinghouse 
incentive system generates one of four status codes. A deposit succeeded status 
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code indicates that the value transfer transaction was committed (e.g., the 
merchant account was debited and the consumer account was credited). A 
second type of status code indicates that the request for authorization has been 
denied due to a condition detected in the fraud control procedures. A third type 
of status code, which also connotes a denied authorization status, indicates that 
there is insufficient value in the merchant's account to execute the transaction. 
An additional type of denied status code indicates that the consumer credential, 
as identified through the authentication token, is insufficient. For example, the 
authentication token, which identifies the consumer, may not be sufficient to 
verify the consumer is the person or entity that the consumer purports to be. 

In one embodiment, the clearinghouse incentive system records 
information regarding the transaction so as to compile profiles regarding 
transactions in the incentive program. For example, from the clearinghouse 
profiles, the clearinghouse may generate information identifying a type of 
consumer that participated in one or more promotional activities sponsored by the 
merchant. The clearinghouse may generate profiles across all merchants to 
indicate the type of consumer that is attracted to particular types of promotions. 
With the RFA and response message information, the clearinghouse incentive 
system may generate numerous types of profiles. 

Also, as shown in block 650 of Figure 6, the clearinghouse incentive 
system digitally signs and encrypts the response message. In one embodiment, 
the clearinghouse incentive system utilizes a symmetric cryptography algorithm 
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to encrypt the response message with the merchant's secret key. However, any 
algorithm may be used to digitally sign and encrypt the response message. 

As shown in block 660 of Figure 6, the clearinghouse incentive 
system transmits the response message from the clearinghouse location to the 
merchant location over the Internet. At the merchant location, the remote 
incentive management system decrypts the response message, as well as verifies 
the authenticity of the message through analysis of the digital signature as shown 
in block 670. The status of the message, as indicated in the response message 
status code, is recorded or logged in the transaction log 320 (Figure 3) as shown 
in block 680. If the RFA message was generated in the asynchronous 
retransmission mode (see below), then the pending status for the asynchronous 
transaction is removed from the asynchronous transaction log. As shown in 
block 690, the remote incentive management system delivers a message to the 
consumer to indicate the status of the transaction. 

In a preferred embodiment, the value transfer network of the 
incentive system insures reliable transfer of value transactions. As discussed 
above, the first call to the RFA-API 310, initiated after the consumer enters the 
earning activity, ensures that the remote incentive management system (e.g., 
server) is operable. This procedure minimizes system failure by indicating to the 
consumer, before the consumer completes the earning activity, that a failure has 
occurred. Although the remote incentive management system may be operable, 
a failure may occur in transmitting the RFA message from the remote incentive 
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management server to the clearinghouse (e.g. , an Internet failure) . For purposes 
of nomenclature, the real-time response to a consumer, as described in 
conjunction with Figures 2a-2c, is the synchronous mode of operation. If a 
failure occurs in providing a real-time response to the value transfer, then the 
remote incentive management system enters an asynchronous retransmission 
mode. 

In general, when operating in the asynchronous retransmission 
mode, the remote incentive management system generates RFA messages on its 
own initiative. In one embodiment, value transfers, which are not successfully 
executed due to a failure in the value transfer network, are signed, encrypted, 
and logged in an asynchronous transaction log. For this embodiment, RFA 
messages logged in the asynchronous transaction log are signed and encrypted to 
prevent the unauthorized tampering of RFA messages. Periodically, the remote 
incentive management server 315 initiates transfer of an RFA message on its own 
initiative. For example, if the failure in the value network is attributable to the 
Internet, then the remote incentive management system resends the RFA message 
periodically. In one embodiment, when operating in the asynchronous 
retransmission mode^ if a large amount of value is transferred to the consumer, 
then the incentive management system sends an e-mail message to the consumer 
to verify that value has been awarded to the consumer. As discussed above in 
conjunction with Figure 2c, if a network failure does occur, the consumer is 
notified that value will be transferred pending compliance with the incentive 



WO 00/21008 . PCT/US99/23077 

34 

program conditions. If an asynchronous retransmission mode attempt is 
successful, such that the remote incentive management system receives a 
response message with a success status code, then the asynchronous 
retransmission mode transaction is removed from the asynchronous 
retransmission mode log. 

If after several attempts the value transfer is unsuccessful, then the 
merchant notifies the clearinghouse of the value transfer via alternative means 
{e.g., means other than message transmission over the Internet). This 
notification, via alternative means, insures reliability of the value transfer. 
Under this condition, the remote incentive management system may log the 
transactions to a permanent storage medium. Through use of the permanent 
storage medium, the transactions may be transferred to the clearinghouse, 
including physically transferring the permanent storage medium to the 
clearinghouse. Accordingly, the incentive system of the present invention 
ensures reliable service to deposit value in a consumers account. 

In one embodiment, to further ensure reliability of the value transfer 
network, the remote incentive management system and the clearinghouse 
incentive system periodically execute "ping" transactions. For this embodiment, 
the remote incentive management system periodically sends a message, to 
execute the ping transaction, that tests the communications link between remote 
incentive management system and the clearinghouse incentive system. At a 
minimum, the information, associated with a ping transaction, is signed and 
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encrypted, and includes a time stamp to identify when the message was sent. 
However, the message may include any parameter. If successful, the remote 
incentive management system receives a signed and encrypted response from the 
clearinghouse incentive system, which also includes a time stamp to indicate 
when the response was sent. Similarly, the response may include any parameter. 
Also, the clearinghouse incentive system may initiate the ping transaction. 

The remote incentive management system, residing at the merchant's 
location, may be administered remotely. In general, any number of functions, 
pertaining to the remote incentive management system, may be remotely 
administered. For example, remote administration may include functions: to 
read the transaction log, to update software for the remote incentive management 
system, to shut down one or more incentive programs, to update the IP address, 
to change the frequency of the ping operation, etc. In one embodiment, the 
remote incentive management system is administered from the clearinghouse, 
through use of software running on a server at the clearinghouse. 

Figure 7 illustrates one embodiment of a remote incentive 
management system implemented at the merchant's location. The merchant web 
server 300 is shown coupled to the incentive management system 400, which in 
one embodiment, comprises a separate server. As discussed above, the remote 
incentive management system may be implemented on a single server. In one 
embodiment, the merchant's implementation on the merchant web server 300 
includes a CGI program, designated as box 700 on Figure 7. However, the 
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functionality for the merchant's web server 300 may be implemented using 
NSAPI, IS API, and other similar server side scripting techniques. The double 
line, which terminates in an arrow, signifies that the CGI program 700 runs on 
the merchant web server 300. In general, the CGI program 700 includes three 
basic functions. First, the CGI program 700 defines all parameters associated 
with the earning activity, including verification of completion of the earning 
activity. The CGI program, as a second function listed in block 700, calls the 
remote incentive management routines for a request for authorization (RFA) to 
transfer value to a consumer. As shown in Figure 3, in one embodiment, the 
merchant web server software calls the RFA- API 310, shown in Figure 7 in box 
310. As discussed above, the RFA- API 310 is a hook into the software of the 
remote incentive management system 400. As a third basic function, the CGI 
program 700 displays responses/results to the consumer (see Figures 2a, 2b, and 
2c). The arrow, which couples the web server 300 to the remote incentive 
management system 400, may be a network connection over a local area network 
(LAN). 

For this embodiment, the merchant fully implements the promotion 
functionality on the merchant web server 300. This implementation permits the 
merchant to maintain a customized web site while implementing the incentive 
program. If a merchant, prior to implementing the incentive program, has 
functionality on a web page to support electronic commerce, then the merchant 
need only modify the web site to include the promotional aspects, such as the 
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addition of promotional pages. Accordingly, the merchant has fiill control and 
flexibility to implement the functionality to support the earning activity. 

Consumer Private Label Currency Redemp tion- 

Referring again to Figure 3, one embodiment for a consumer private 
label currency redemption system is illustrated. The consumer, which gains 
access to the Internet via the consumers Internet Service Provider 330, locates 
a clearinghouse Internet site. This connection is illustrated by the "Z" shaped 
lines and corresponding arrows on Figure 3. In one embodiment, the 
clearinghouse web site is supported by the clearinghouse incentive management 
server 340. Alternatively, a separate server, dedicated to the redemption 
process, may be implemented. The clearinghouse incentive management server 
340 has access to the consumer account 335, as indicated by the line coupling the 
server 340 with the consumers account 335. 

In general, the process of redemption involves a consumer that 
requests the transformation of the private label currency value into some other 
form of value. Figure 8 is a flow diagram illustrating one embodiment for 
consumer private label currency redemption. As shown in block 800, the 
consumer contacts the clearinghouse web site that supports the private label 
currency redemption. The redemption process may be implemented on one or 
more web pages on the clearinghouse web site. A consumer, prior to redeeming 
any value, must authenticate himself or herself by effectively binding the 
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consumer's network identity, used to earn the value, to the consumer's social 
identity. As shown in block 810, the consumer authenticates himself or herself 
to the clearinghouse incentive system. In one embodiment, to authenticate 
themselves, consumers submit a digital identification as well as a password if the 
consumer has an account with the clearinghouse. If the consumer does not have 
an account, then the consumer must open a consumer account. In one 
embodiment, the authentication step is the same information used to generate the 
authentication token in the RFA message (Table 1). 

In general, to open an account, the consumer supplies information 
to the clearinghouse. The type and amount of information supplied varies 
depending upon how risk is allocated for the incentive program. In one 
embodiment, at a minimum, the consumer supplies, to the clearinghouse, his/her 
name and e-mail address. Thereafter, the clearinghouse sends an e-mail to the 
consumer requesting additional information. In response to this e-mail, the 
consumer supplies, to fully activate an account: history of participation in a 
merchant's earning activities, an identification (ID) to uniquely identify the 
consumer, and/or a digital certificate. In one embodiment, the digital certificate 
conforms to a digital certificate as defined by the standard x509.3. 

As shown in blocks 810 and 870, if the consumer is not 
authenticated, then the consumer receives notice that the authentication has 
failed. If the authentication is successful, then the clearinghouse incentive system 
displays account information, for the corresponding consumer, as well as a 
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redemption catalog as shown in blocks 810 and 820. In general, the account 
information includes the amount of value or private label currency earned by the 
consumer. For example, the account information may indicate the number of 
points awarded to the consumer. 

The redemption catalog lists the goods and services available to the 
consumer for redemption of value. The services and goods may include frequent 
flyer miles, cash, credit, or any other goods and/or services. The redemption 
catalog may include, in addition to the list of goods and/or services, the amount 
of value required to redeem various goods and/or services. The redemption 
catalog may also indicate a relative correspondence of value between the 
redemption catalog and the consumers earned value. For example, the consumer 
may redeem, for each point earned, one frequent flyer mile. 

As shown in block 830 of Figure 8, to redeem value, a consumer 
chooses a redemption item from the redemption catalog. In general, this step 
involves some way for the consumer to transform value from the private label 
currency system into a good and/or a service. As shown in block 840 of Figure 
8, the clearinghouse incentive system executes fraud control procedures. In 
general, the fraud control procedures insure that the consumer meets some 
statistical criteria prior to execution of the redemption process. For example, in 
one embodiment, more stringent fraud control procedures may be executed where 
the consumer attempts to redeem a large amount of value. If fraud is detected 
(e.g., the consumer does not meet the statistical criteria), then the consumer 
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receives notice that value will not be redeemed as shown in blocks 850 and 870. 
Alternatively, if fraud is not detected, then the incentive system debits the 
consumer account, and begins the supplier fulfillment process as shown in block 
860. 

In general, supplier fulfillment involves initiating the process to 
deliver the redemption good and/or service. For example, if the redemption item 
is frequent flyer miles, then the clearinghouse executes the necessary steps to 
deliver the redeemed value to the supplier, an airline. In turn, the supplier 
actually confers the redeemed value. For the frequent flyer miles award program 
example, the supplier, an airline, awards the frequent flyer miles to the 
consumer. 

In the final step of the on-line redemption process, the consumer 
receives notice of the updated account information as shown in block 870. The 
updated account information includes the new total of value or private label 
currency held by the consumer. For example, if the consumer, prior to 
redemption, had 2,000 points, and redeemed 1,000 points for a redemption item, 
then the incentive system displays the balance of 1,000 points as the updated 
account information. 

As discussed above, consumers, to participate in an earning activity 
as well as redeem value, authenticate themselves. In general, a consumer 
authentication refers to the binding of a net identification to a social identification 
for a consumer. An authentication requirement raises the barrier of entry to a 
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consumer to start earning value through an earning activity. It is desirable to 
lower the entry barrier to entice consumers to perform earning activity to earn 
value. However, if the consumer authentication requirement is minimal, then the 
system is susceptible to fraud and abuse. For example, a "Robin Hood" attacker 
may attempt to drain all value from a merchant, even though the Robin Hood 
attacker has no intent to redeem the value. A "Doppleganger" attacker attempts 
to appear as many people, and the attacker seeks to gain an excessive amount of 
value. Thus, for the preferred embodiment, a balance is drawn between the 
competing interests of having a low authentication barrier to entice consumers to 
earn value verse having a high authentication barrier to prevent fraud and abuse 
of an incentive program. 

In one embodiment, a first time consumer authentication process 
creates clearinghouse members by generating a consumer account with the 
clearinghouse (e.g. , account information exists for the consumer in the consumer 
account database 335 (Figure 3)). The first time consumer authentication is a 
one time only process. After completion of the first time consumer 
authentication process, the consumer performs a "normal" authentication, prior 
to entering an earning activity, whereby a consumer provides a UID-password 
or a public key certificate (e.g. , the authentication token). 

In one embodiment, the incentive system supports deferred 
authentication. In general, deferred authentication permits a consumer to enter 
an earning activity prior to the first time authentication. For this scenario, the 
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consumer value earned during the earning activity is deposited into an inactive 
account. One rationale to implement a deferred authentication system is that 
once consumers earn value, they will be more motivated to perform the more 
rigorous first authentication procedure. For purposes of nomenclature, the 
inactive account is referred to as a "pending transaction pool. " 

In allowing deferred authentication, value is held in the pending 
transaction pool until the consumer performs the first authentication. Thus, value 
is only redeemable after the value has been transferred from the inactive account 
to a consumer account (e.g., after the first authentication). In a preferred 
embodiment, the value held in the pending transaction pool expires after a 
predetermined amount of time, such as two weeks. Value held in the pending 
transaction pool may expire for any number of reasons. The consumer, who 
completed the earning activity prior to the first consumer authentication, has 
forgot to perform the first authentication, and therefore the value has expired 
unintentionally. Value in the pending transaction pool may also expire from an 
attempted security breach, or an attempted denial of service attack. 

The use of the pending transaction pool presents an additional issue 
of billing between the clearinghouse and the merchant. In one embodiment, the 
merchant is billed (e.g. , value is debited from the merchant account) when value 
enters an inactive account. In a second embodiment, the merchant account is 
debited only when the consumer performs the first authentication, and the value 
is transferred to a specific consumer account. In a third embodiment, a 
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combination of the first two embodiments is implemented, such that a portion of 
the value is debited from the merchant's account when the value enters an 
inactive account, and if the value is transferred to a specific consumer account, 
then the remaining portion of value is debited from the merchant account. 



Computer System: 

Figure 9 illustrates a high level block diagram of a general puipose 
computer system in which the servers of the inventive system of the present 
invention may be implemented. A computer system 1000 contains a processor 
unit 1005, main memory 1010, and an interconnect bus 1025. The processor unit 
1005 may contain a single microprocessor, or may contain a plurality of 
microprocessors for configuring the computer system 1000 as a multi-processor 
system. The main memory 1010 stores, in part, instructions and data for 
execution by the processor unit 1005. If the incentive system of the present 
invention is wholly or partially implemented in software, the main memory 1010 
stores the executable code when in operation. The main memory 1010 may 
include banks of dynamic random access memory (DRAM) as well as high-speed 
cache memory. 

The computer system 1000 further includes a mass storage device 
1020, peripheral device(s) 1030, portable storage medium drive(s) 1040, input 
control device(s) 1070, a graphics subsystem 1050, and an output display 1060. 
For purposes of simplicity, all components in the computer system 1000 are 
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shown in Figure 9 as being connected via the bus 1025. However, the computer 
system 1000 may be connected through one or more data transport means. For 
example, the processor unit 1005 and the main memory 1010 may be connected 
via a local microprocessor bus, and the mass storage device 1020, peripheral 
device(s) 1030, portable storage medium drive(s) 1040, graphics subsystem 1050 
may be connected via one or more input/output (I/O) busses. The mass storage 
device 1020, which may be implemented with a magnetic disk drive or an optical 
disk drive, is a non-volatile storage device for storing data and instructions for 
use by the processor unit 1005. In the software embodiment, the mass storage 
device 1020 stores the incentive system software for loading to the main memory 
1010. 

The portable storage medium drive 1040 operates in conjunction 
with a portable non-volatile storage medium, such as a floppy disk or a compact 
disc read only memory (CD-ROM), to input and output data and code to and 
from the computer system 1000. In one embodiment, the incentive software is 
stored on such a portable medium, and is input to the computer system 1000 via 
the portable storage medium drive 1040. The peripheral device(s) 1030 may 
include any type of computer support device, such as an input/output (I/O) 
interface, to add additional functionality to the computer system 1000. For 
example, the peripheral device(s) 1030 may include a network interface card for 
interfacing the computer system 1000 to a network. 

The input control device(s) 1070 provide a portion of the user 
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interface for a user of the computer system 1000. The input control device(s) 
1070 may include an alphanumeric keypad for inputting alphanumeric and other 
key information, a cursor control device, such as a mouse, a trackball, stylus, or 
cursor direction keys. In order to display textual and graphical information, the 
computer system 1000 contains the graphics subsystem 1050 and the output 
display 1060. The output display 1060 may include a cathode ray tube (CRT) 
display or liquid crystal display (LCD). The graphics subsystem 1050 receives 
textual and graphical information, and processes the information for output to the 
output display 1060. The components contained in the computer system 1000 are 
those typically found in general purpose computer systems, and in fact, these 
components are intended to represent a broad category of such computer 
components that are well known in the art. 

The incentive system may be implemented in hardware, software, 
or both. For the software implementation, the incentive management system is 
software that includes a plurality of computer executable instructions for 
implementation on a general purpose computer system (e.g., one or more 
servers). Prior to loading into a general purpose computer system, the incentive 
system software may reside as encoded information on a computer readable 
medium, such as a magnetic floppy disk, magnetic tape, and compact disc read 
only memory (CD - ROM). In one hardware implementation, the incentive 
system may comprise a dedicated processor including processor instructions for 
performing the functions described herein. Circuits may also be developed to 
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perform the functions described herein. The transaction log, customer account 
and merchant account may be implemented as databases stored in memory for 
use by the incentive system software running on a server. 

Although the present invention has been described in terms of 
specific exemplary embodiments, it will be appreciated that various modifications 
and alterations might be made by those skilled in the art without departing from 
the spirit and scope of the invention. 
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CLAIMS 

What is claimed is: 

1 LA method for implementing an on-line incentive system, said method 

2 comprising the step of: 

3 providing, at a merchant's web site, a means for a consumer to enter an 

4 earning activity to earn value from said merchant; and 

5 transferring value from said merchant to said consumer for participation in 

6 said earning activity, if said consumer qualifies, without re-directing said 

7 consumer away from said merchant's web site, whereby said consumer's focus 

8 of activity remains at said merchant's web site. 

1 2. The method as set forth in claim 1 , wherein the step of transferring 

2 value comprises the step of providing, at a merchant's web site, a means for 

3 detennining whether said consumer qualifies to earn value by defining parameters 

4 that determine said earning activity, wherein said consumer remains at said 

5 merchant's web site to earn value from said merchant. 

4 1 3. The method as set forth in claim 1 , further comprising the step of 

2 requesting authorization to a clearinghouse site to transfer value from said 

3 merchant to said consumer. 



1 



The method as set forth in claim 1, further comprising the steps of: 
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executing the step of providing a means for a consumer to enter an earning 
activity and a step of providing a means for determining whether said consumer 
qualifies to earn value on a merchant's web server; and 

executing a step of requesting authorization to a clearinghouse site to 
transfer value from said merchant to said consumer on a server distinct from said 
merchant's web server. 

5 . The method as set forth in claim 1 , wherein the step of providing a 
means for a consumer to earn value through an earning activity comprises the 
step of providing a means for a consumer to lend attention in a manner pre- 
defined by said merchant. 

6. The method as set forth in claim 1 , wherein the step of providing a 
means for a consumer to earn value through an earning activity comprises the 
step of providing a means for a consumer to send information requested by said 
merchant. 

7. The method as set forth in claim 1, wherein the step of providing a 
means for a consumer to earn value through an earning activity comprises the 
step of providing a means for a consumer to conduct an activity in a manner pre- 
defined by said merchant. 
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8. The method as set forth in claim 1 , wherein the step of providing a 
means for a consumer to earn value through an earning activity comprises the 
step of providing a means for a consumer to purchase merchandise offered by the 
merchant. 



9. A method for transferring value, conferred by a merchant, to a 
consumer, said method comprising the steps of: 

generating, at said merchant's location, a request to authorize a value 
transfer from a merchant account for said merchant to said consumer; 

dispatching said request from the merchant site to a clearinghouse site; 

authorizing, at said clearinghouse site, said value transfer from said 
merchant account for said merchant to said consumer; 

generating, at said clearinghouse site, a response message that indicates a 
status for said authorization; and 

generating a response to said consumer that indicates said status of said 
authorization request. 

10. The method as set forth in claim 9, further comprising the steps of: 
depositing said value into an account for said consumer; and 

debiting said value in said merchant's account. 
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1 11. The method as set forth in claim 9, further comprising the step of 

2 re-sending said request message if a failure occurs in transmission between said 

3 merchant site and said clearinghouse site. 

1 12. The method as set forth in claim 9, further comprising the step of 

2 logging said value transfer transaction at said merchant location. 

1 13 . The method as set forth in claim 12, wherein the step of logging said 

2 value transfer transaction comprises the step of logging said value transfer 

3 transaction as human readable text. 

1 14. The method as set forth in claim 12, wherein the step of logging said 

2 value transfer transaction further comprises the step of digitally signing and 

3 encrypting said value transfer transaction. 

1 15. The method as set forth in claim 9, wherein the step of generating 

2 a request to authorize comprises the step of encrypting said request message 

3 utilizing a private key cryptographic algorithm. 



1 

2 
3 



16. The method as set forth in claim 9, further comprising the steps of: 
providing a means, for said merchant, to capture said value transfer; and 
providing a means, for said merchant, to execute a charge back against said 
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4 value transfer. 

1 17. The method as set forth in claim 9, wherein the step of authorizing 

2 said value transfer comprises the step of executing fraud control procedures to 

3 detect consumer attempting to defraud said incentive system. 

1 18. The method as set forth in claim 9, wherein the step of authorizing 

2 said value transfer comprises the step of authorizing said value transfer for 

3 consumers not yet authenticated with said incentive system. 

1 19. The method as set forth in claim 18, further comprising the step of 

2 transferring said value into an inactive account pending authentication by said 

3 consumer. 

1 20. A method for implementing an incentive system, said method 

2 comprising the steps of: 

3 providing, at a merchant site, a means for a consumer to earn value, 

4 conferred by said merchant, through an earning activity; 

5 transferring, from said merchant to said clearinghouse, said value conferred 

6 in the form of a general private label currency; and 

7 providing, at said clearinghouse, a means for said consumer to redeem said 

8 private label currency value for goods and services. 
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